Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9710/000013_owner-urn-ietf _Mon Oct 27 14:55:09 1997.msg

Internet Message Format | 1997-10-28 | 5KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id OAA25584
    for urn-ietf-out; Mon, 27 Oct 1997 14:55:09 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with ESMTP id OAA25570
    for <[e-mail]>; Mon, 27 Oct 1997 14:55:06 -0500 (EST)
Received: from beethoven.bunyip.com (beethoven.Bunyip.Com [192.197.208.5])
    by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id OAA04541;
    Mon, 27 Oct 1997 14:54:30 -0500 (EST)
Received: from localhost (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) with SMTP id OAA05775; Mon, 27 Oct 1997 14:54:39 -0500
X-Authentication-Warning: beethoven.bunyip.com: leslie owned process doing -bs
Date: Mon, 27 Oct 1997 14:54:39 -0500 (EST)
From: Leslie Daigle <[e-mail]>
To: Al Gilman <[e-mail]>
cc: [e-mail], Klaus Weide <[e-mail]>, [e-mail],
        [e-mail]
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
Reply-To: Leslie Daigle <[e-mail]>
Errors-To: [e-mail]

If you want to have a discussion about whether or not fragment identifiers
make sense in URNs, I suggest that chopping the [e-mail] mailing
list out of the CC list was poor optimization...

On Fri, 24 Oct 1997, Al Gilman wrote:
>
> Various of the schemes now called URLs make more sense as names
> than as locators.
>
> And relative references such as 'ibid' and 'loc_cit' abound in
> the natural-language reference vocabulary we should try to serve

The problem is not whether, in an abstract sense, relative references
make sense in conjunction with names rather than locators.  The issue
is one of whether or not the defined implementation of "# fragments"
for URLs is applicable to the defined implementation of URNs.

There is a long discussion on the topic that you will find in the URN
working group's mail archive:

    ftp://ftp.bunyip.com/mailing-lists/urn-ietf.archive

You can review this, and the URN documents, if you really want to pursue
this thread.

My point is that if all of the URL syntax/semantics is to be applied
to URIs in general, a careful and informed analysis by people who understand
what _has_ been done in _both_ areas is necessary.  And, I don't see
that in this discussion.

For example,
> If URNs don't like the fragment rules that go with URLs, it is
> probably because they are not really accessing the same media
> types.  If you can't index into a resource after retrieving it by
> an URN with the same semantics as if you retrieved it with an
> URL, you just need to define a new object class with appropriate
> interior access methods and register that class as an internet
> media type and voila -- URNs with fragments.

Bear in mind that with URNs you are not referring to a single media
type -- a single URN _can_ refer to an ascii file, a PS file, a word
document, a bitmapped image of a page, etc.  You can't even reliably
define "paragraph", "page", "file".  The only level at which
relative references might make sense within URNs is between URN-identified
objects (e.g., volumes in a a series) -- i.e., media-type-independent
references.

Note that I am _not_ saying relative references _can't_ be useful and
usable with URNs.  But any previous discussion has suggested that it
would be very namespace-specific (and by "namespace", I mean a subscheme
within the space of URN:, for the uninitiated), and there will be namespaces
for which it is not relevant.

What I have seen done with the URL syntax/semantics spec in the past is
that any feature in it that is described as "optional" then becomes _expected_
of any "scheme" that falls within its purview.  E.g., people would
expect retrofitted implementations of "# fragment" semantics to URN identifiers
because the spec says they _could_.  That's a lot of  baggage that I
don't see URNs needing to inherit.

> Hope this helps.  I don't think that the URL spec ties the hands
> of the URN inventors to any significant degree.

Well, what you are saying here is that you believe you could implement _a_
naming system within the constraints of the URL specifications, not that
a system that met the requirements of URNs (as has been defined by the
URN working group) is not constrained by this spec.

Leslie.


----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you
                          _are_."                 Bunyip Information Systems
                                                  [phone]
                      -- ThinkingCat              [e-mail]
----------------------------------------------------------------------------